home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / tsql / doc / tsql.mail / 000161_rts _Mon Jul 5 15:32:21 1993.msg < prev    next >
Internet Message Format  |  1996-01-31  |  4KB
  1. Received: from boojum.CS.Arizona.EDU by optima.CS.Arizona.EDU (5.65c/15) via SMTP
  2.     id AA21534; Mon, 5 Jul 1993 15:32:22 MST
  3. Date: Mon, 5 Jul 1993 15:32:21 MST
  4. From: "Rick Snodgrass" <rts>
  5. Message-Id: <199307052232.AA16364@boojum.cs.arizona.edu>
  6. Received: by boojum.cs.arizona.edu; Mon, 5 Jul 1993 15:32:21 MST
  7. To: tsql@cs.arizona.edu
  8. Subject: SQL temporal language extensions
  9.  
  10. One major objective of the temporal database infrastructure workshop
  11. (held three weeks ago in Arlington, TX) was to initiate the design of
  12. a consensus temporal extension of SQL.  There were three conflicting
  13. viewpoints on such an extension voiced by the workshop participants
  14. (with associated rationales, not repeated here):
  15.  
  16. (a) With the addition of an interval data type, there will be
  17. sufficient support in SQL2/3's data model to support applications
  18. using temporal data.  Further temporal support within the data
  19. model should not be added.
  20.  
  21. (b) SQL2, and the proposed SQL3, require temporal support to be added
  22. to their data model and query language. A two-pronged effort should be
  23. initiated, the first being a short-term effort to define a temporal
  24. extension to SQL2 and the second being a long-term effort to define a
  25. comprehensive extension to SQL3.
  26.  
  27. (c) Temporal support should be added, but only SQL3 should be
  28. extended.
  29.  
  30. These three viewpoints are clearly at variance. So, instead of a
  31. single consensual effort, which appears to be unattainable, three
  32. separate efforts have been initiated, each reflecting the approach
  33. espoused by a significant portion of the TDB community, and together
  34. enabling further progress. The following working groups have been
  35. started. If you would like to participate in one of these working
  36. groups, please contact the group coordinator.
  37.  
  38. * The SQL2/3 working group
  39.     Those agreeing with viewpoint (a) will define an interval data
  40. type and write SQL2 (or SQL3) queries for the benchmark queries, so
  41. that this approach can be compared with other proposals. Nikos
  42. Lorentzos <elio@isosun.ariadne-t.gr> has volunteered to coordinate
  43. this effort.
  44.  
  45. * The TSQL2 working group
  46.     Those agreeing with viewpoint (b) will define a short-term
  47. temporal extension to SQL2. I have volunteered to coordinate this
  48. effort.
  49.  
  50. * The TSQL3 working group
  51.     Those agreeing with viewpoint (b) or with viewpoint (c) will
  52. define a long-term temporal extension to SQL3. Gene Wuu
  53. <wuu@ctt.bellcore.com> has volunteered to coordinate this effort.
  54.  
  55. The initial reports of these working groups, if they are completed by
  56. August 23, will be attached to final report of the workshop.  However,
  57. the activities of these working groups are also relevant apart from
  58. the workshop, and so should not be prescribed by it.  The workshop can
  59. be viewed as an impetus for further consensual infrastructure
  60. activities withing the temporal database community.
  61.  
  62. The specific charters of the working groups will be determined by the
  63. coordinators. I now turn to discussing the particulars of the TSQL2
  64. working group.
  65.  
  66. The TSQL2 working group design will proceed in the context of the
  67. following constraints.
  68.  
  69. * The initial design must be completed by August 23, 1993.
  70.  
  71. * The design will be based on SQL2. In particular, none of the
  72.     significant extensions envisioned in SQL3 will be assumed
  73.     to be present.
  74.  
  75. * Initially, the language design will support user-defined time and
  76.     valid time. Support for transaction time may be added later.
  77.  
  78. * The design will be implementable in the context of conventional
  79.     relational database technology. In particular, implementations
  80.     of the data model and query language constructs will be
  81.     possible without necessitating major changes to conventional
  82.     database management systems.
  83.  
  84. * Discrete time will be assumed.
  85.  
  86. * Past and future valid time will be supported.
  87.  
  88. The activities of this working group will be parallel to those of the
  89. SQL2/3 and TSQL3 working groups. Interaction in the medium term
  90. between these groups will attempt to arrive at consistent approaches.